CD Ware Multimedia 1995 May

home *** CD-ROM | disk | FTP | other *** search

/ CD Ware Multimedia 1995 May / cd Ware (Juegos) Epimundo.iso / DOS / TOOLS / BLDHOUND.ZIP / B.DOC < prev next >

Wrap

Text File | 1988-05-28 | 82.3 KB | 2,808 lines

E G ┌──────────────────────────────────────────────────────────────────────────┐ │ │ │ BLOODHOUND (TM) │ │ │ │ A quality assurance program for the IBM PC │ │ │ │ │ │ │ │ │ └──────────────────────────────────────────────────────────────────────────┘ FH Version 1.00 Richard Fencel 1376 Deerpark Drive #22 Fullerton, Ca. 92631 (714) 760 - 9196 (c) Copyright 1987 EGBloodhoundFH EG CONTENTS FH 1.0 WHAT IS BLOODHOUND?........................................... 2 2.0 HOW DOES BLOODHOUND WORK?..................................... 4 3.0 FEATURES...................................................... 6 4.0 INSTALLING BLOODHOUND......................................... 7 5.0 TUTORIAL...................................................... 8 6.0 COMMAND LINE OPTIONS.......................................... 13 6.1 "-r" record test .................................. 13 6.2 "-m" make screen images for test........................ 14 6.3 "-p" playback test, "-s" stop on failure................ 15 6.4 "-a" append to test..................................... 17 6.5 "-c" close file after each entry, "-d" define disk drive 18 6.6 "-o" output screen comparisions to printer.............. 19 7.0 SCREEN CAPTURES UNDER PROGRAM CONTROL......................... 20 8.0 SETTING OF TIME AND DATE...................................... 22 9.0 MANUAL EDITING OF TESTS....................................... 23 10.0 UTILITY VIEW.EXE............................................. 25 11.0 PROGRAM BREAKPOINTS.......................................... 27 12.0 CUSTOMIZING BLOODHOUND....................................... 32 13.0 BLOODHOUND FILE STRUCTURE.................................... 33 14.0 MEMORY REQUIREMENTS.......................................... 34 15.0 COMPATIBILITY WITH SUPERKEY.................................. 35 16.0 HINTS AND SUGGESTIONS........................................ 36 17.0 LIMITATIONS.................................................. 37 18.0 ERROR MESSAGES............................................... 39 19.0 LICENSE AGREEMENT AND DISCLAIMER............................. 41 EGMay 8, 1988 Page 1FH EGBloodhoundFH EG 1.0 WHAT IS BLOODHOUND? FH Have you ever made a change to a software program, successfully tested the change, and then discovered later the change had bombed out other areas? Wouldn't it be nice to be able to do a single test command that proves your program in its entirety still works? And if it doesn't still work, then how about a debug command that executes your program to just prior to where the bomb occurs and then halts, allowing you to watch the bomb in single step? Lastly, have you ever discovered a surprise bug in your program and then pulled your hair out trying to recall exactly what keystrokes caused the blow-up? Enter BLOODHOUND, which solves all of the above problems. Bloodhound is a shareware product. Feel free to give a copy to your friends. However, if you leave Bloodhound installed on your machine for more than 30 days, you are obligated to pay a license. The license is as follows: 1 machine $50 additional machines $10 or network nodes site license $100 corporate license $500 (1-1000 employees) corporate license $1000 (greater than 1000 employees) A site license covers unlimited copying rights to Bloodhound at one address. A corporate license covers unlimited copying rights to Bloodhound throughout the entire corporation around the world. Site and corporate licenses free the owners from copyright liability (i.e. lawsuits) throughout the area over which the license covers. The site or corporate license allows any customers of the licensee to use Bloodhound for the purpose of testing products owned by the licensee. Should a corporate license be purpose with less than 1000 employees for $500, no further license payment is required if the corporation grows beyond 1000 employees. EGMay 8, 1988 Page 2FH EGBloodhoundFH Please make checks payable to: Richard Fencel 1376 Deerpark Drive #22 Fullerton, Ca. 92631 Licensees are entitle to telephone technical support on an "as available" basis. Please call (714) 524 - 6604 evenings/weekends/holidays. There are currently no planned updates to Bloodhound (eg. graphics screens or OS2). EGMay 8, 1988 Page 3FH EGBloodhoundFH EG 2.0 HOW DOES BLOODHOUND WORK? FH BLOODHOUND works by building a "bloodhound test". This is simply recording your keystrokes while you exercise your program and capturing the screen images resulting therefrom. Then when you later make a change to your program and wonder if the change bombed any already working code, you tell BLOODHOUND to re-run the key sequence and check the new screen images against the "known good" images. To create a "bloodhound test", you issue the following command from DOS: C>b -r yourprog.exe The above command causes your program to execute as normal but with BLOODHOUND running "underneath" and recording every keystroke ("-r" option indicates "record keystroke"). That is, BLOODHOUND (the program "bomb.exe") is the "background" program and "yourprog.exe" is the "foreground program". Now exercise your program's various features until you have a complete test of your software. Your software can either be a computer program, spreadsheet template, or any program that is expected to have a known display after a set of known keystrokes. When you have a complete test, exit your foreground program to DOS. Then type: C>b -m yourprog.exe This will replay all the keystrokes you just stored, while at the same time automatically saving the screen image after each keystroke or screen scroll ("-m" option indicates "make screen images"). The value of having the bloodhound test is apparent when you make a change to your software and want to know if everything else still works. To exercise the bloodhound test you merely type from DOS: C>bomb -p yourprog.exe BLOODHOUND runs thru the key sequence captured earlier and confirms that all the screen displays are identical to those displayed when the test was created ("-p" option indicates "playback test"). If there are discreprancies, they are output to the printer (or disk file) along with where they occurred in the test program. For programmers, there exists the option of having BLOODHOUND automatically set a "breakpoint" in the test program at the keystroke just prior to where a bomb occurs. Then the bloodhound test can be re-run and the breakpoint will activate. This "breakpoint" is based on an arbitrary software interrupt which returns normally AX = 0 but is modified to return AX = 1 when a EGMay 8, 1988 Page 4FH EGBloodhoundFH breakpoint is encountered. The programmer makes use the breakpoint by inserting anywhere in his code a call to the chosen interrupt and then testing for the returned value of AX. (The most logical place to do the interrupt call would be a central routine that is called whenever the keyboard is read). If upon returning from the interrupt, AX = 1 then the breakpoint has occurred and the programmer can transfer control to a trap location. Once in the trap location, the programmer can examine whatever variables he chooses and then single step his program right up thru the bomb. Note that the bomb-out can be not only a screen display which failed to compare with a known "good" screen but also a catastrophic type error such as a keyboard freeze or the infamous "PARITY ERROR" message. EGMay 8, 1988 Page 5FH EGBloodhoundFH EG 3.0 FEATURES FH Here is a summary of BLOODHOUND's features: (1) Captures an unlimited number of keystrokes and screens in text mode (graphics modes are planned for future releases). (2) User program itself can capture screens at arbitrary points, i.e. keystrokes not required. This is useful in environments where electrical signals, not user interaction drive the program (eg. industrial control). (3) Screen images are automatically captured whenever user program causes the screen to scroll (eg. via "printf" statements). (4) During playback, a copy of the original keystroke program is automatically generated with breakpoints inserted wherever a screen comparision failed. This "debug" program can then be played back in a way that allows the user program to stop just prior to when the bomb occurs. This allows registers and variables to be examined at the critical moment. (5) Can be used as a general purpose keyboard recorder whenever any program is executed. This is useful so that if any unexpected bugs occur while a user program is being run, an exact record is retained of what keystrokes were made. BLOODHOUND requires an IBM PC or compatible with at least 320K RAM. Also BLOODHOUND does not support use of keys that do not generate an actual keystroke such as "num lock", "scroll lock", "caps lock" or combinations such as "Ctrl Alt" or "Ctrl Break". EGMay 8, 1988 Page 6FH EGBloodhoundFH EG 4.0 INSTALLING BLOODHOUND FH Create a directory private to BLOODHOUND, eg. "blood". Then dump the entire contents of the BLOODHOUND disk into this subdirectory. Now copy your foreground program to be tested to this directory unless you have "path'ed" to it. EGMay 8, 1988 Page 7FH EGBloodhoundFH EG 5.0 THE BLOODHOUND TUTORIAL FH For the purpose of this tutorial, we are going to use the foreground program called "foregnd.exe". This is a simple "C" language program (source code "foregnd.c", included on your BLOODHOUND disk) that is a one line text editor. Pressing "Enter" clears the line. In addition, pressing F1 prints on the screen a count from 1 to 100. Pressing F10 returns to DOS. Before we begin the tutorial a word of caution: BLOODHOUND will not execute if you have printing job running with the DOS command PRINT.COM. To the begin the tutorial, enter from DOS: C>b -r foregnd.exe We now create an exhaustive test of "foregnd.exe". Type the line: Now is the time for all good men Press F10 to return to DOS. The keys that you just typed are saved in a file called "keys.tst" (it is possible to specify an arbitrary name as we shall see later. However "keys.tst" is the default name). Thus the contents of "keys.tst" are: N o w sp i s sp t h e sp t i m e sp f o r sp a l l sp g o o d sp m e n F10 where "sp" indicates the keystroke "space". However, we still must create accompanying screen images. To do this, enter from DOS: C>b -m foregnd.exe Note that all the keys are played back when "-m" is invoked. At this time the screen images are also captured after each keystroke and stored in a file called "keys.cmp". Now we have a complete bloodhound test consisting of two files, "keys.tst" (the keystrokes that drive up the test) and "keys.cmp" (the screens that are compared against during the test). Now suppose you made a change to "foregnd.exe" and want to assure yourself that the earlier recorded keystrokes still produced the same screens. Simply execute the command: C>b -p foregnd.exe The test plays back the key strokes, compares the resultant screens to the originally recorded screens, and reports no errors. You should see the message: Test "keys" of program "foregnd.exe" now complete Number of failures = 0 The problem with the above example is that it is really is not very interesting since it all works. To see what happens when we have a EGMay 8, 1988 Page 8FH EGBloodhoundFH failure, we are going to playback a test called "bad.tst" which is identical to "keys.tst" except that one keystroke is bad, i.e. the word "men" is mispelled as "man". Thus "bad.tst contains: N o w sp i s sp t h e sp t i m e sp f o r sp a l l sp g o o d sp m a n F10 To see what happens when we execute a test where the screen images do not correspond to the keystrokes, first copy "bad.tst" to "keys.tst" after saving the original file: C>copy keys.tst keys.sav C>copy bad.tst keys.tst Now playback your test modified to give an error: C>b -p -s foregnd.exe Note that we have used the "-s" option during playback which means "stop on failure". This means whenever a screen comparision failure occurs, playback will stop, giving you an opportunity to see exactly how the screens differed when the failure occurs. Regardles of whether the "-s" is used, screens comparision failures are always stored to disk for later perusal. After executing the above command, your test is played back until the screens differ when the word "man" is output rather than "men". When this occurs you will see the screen: EG SAMPLE FOREGROUND PROGRAM "foregnd.exe" Now is the time for all good man ┌──────────────────────────────────────────────────────────────────────────┐ │ BUG DETECTED │ ├──────────────────────────────────────────────────────────────────────────┤ │Press "F" repeatedly to flip between bad screen/good screen ("esc" to │ │return to this menu) │ │ │ │Press "D" repeately to flip between difference in bad screen/good screen │ │("esc" to return to this menu) │ │ │ │Press space bar to continue playback │ │ │ │Press "esc" to cancel playback │ └──────────────────────────────────────────────────────────────────────────┘ Figure 1: BLOODHOUND screen compare failure FH Pressing "F" will bring up the "bad screen", i.e. the one that was shown by the playback. Press "F" again will bring up the "good" screen, i.e. EGMay 8, 1988 Page 9FH EGBloodhoundFH the one that was originally recorded. Pressing "F" again will bring up the bad screen, etc. When tired of this, "esc" returns to the above error menu. To see this in action, press: F (bad screen appears) F (good screen appears) F (bad screen appears again) (esc) (error menu appears) Pressing "D" will show you those chars on the bad screen that are different from those on the good screen. Pressing "D" one more time will show you the chars on the good screen that are different from the bad screen. Press "D" again will show you the bad chars, etc. When tired of this, "esc" returns to the above error menu. To see this in action, press: D (bad screen differences appear) D (good screen differences appear) D (bad screen differences appear again) (esc) (error menu appears) To continue playback from an error, press space bar. To terminate playback completely press esc. Let's try the second screen compare. Press (space bar) We again get a failure. Look again at the differences. Press D (bad screen differences appear) D (good screen differences appear) D (bad screen differences appear again) (esc) (error menu appears) Now lets abort the test completely. Press (esc) and you return to DOS, displaying the message: Test "keys" of program "foregnd.exe" now complete Number of failures = 2 To view test failures, type "VIEW keys" Now suppose you didn't want to sit there and mind the space bar everytime a failure occurred. You then simply execute the playback without the "-s" option. Execute the command: EGMay 8, 1988 Page 10FH EGBloodhoundFH C>b -p foregnd.exe Now the entire test will playback but not stop if there is a failure. You will, however, hear a beep with each failure. When playback is complete, you will see the message: Test "keys" of program "foregnd.exe" now complete Number of failures = 2 To view test failures, type "VIEW keys" (Note that playback terminates automatically if more than 10 failures occur. This "max failure number" can be changed if desired. See section 13.0). The failures are stored in a file called "keys.err" and can be viewed off-line with the program VIEW.EXE as explained in section 10.0. The last part of the tutorial is to add to a test already written. We do this by playing back the original test to the end in "append" mode, and thereafter we are prompted to add keystrokes. First restore the orginal "keys.tst" that we corrupted earlier. Type: C>copy keys.sav keys.tst Note that the last key of "keys.tst" is F10 which returns us to DOS. We must manually edit out this key or we will not be able to add to our test since when the playback is complete we will end up back in DOS. Therefore modify keys.tst using your favorite word processor so that it contains: N o w sp i s sp t h e sp t i m e sp f o r sp a l l sp g o d sp m e n Now execute the test with the "-a" option: C>b -a foregnd.exe Your test will playback (no screen comparisions are done) until you reach the end and you see the message: Appending to test "keys" You may now start typing in the rest of your test, just as if you were using the "-r" option. When complete, re-generate the screens using the "-m" option and you have a fully re-written test. Let's try this. Type: F1 This causes the screen to count from 1-100. When done press enter The last command restores the screen to the one line word processor. Now exit to DOS. Type: EGMay 8, 1988 Page 11FH EGBloodhoundFH F10 Regenerate the test screens by typing: C>b -m foregnd.exe Note that everytime the screen scrolls, the screen image is captured and made part of the test. Playback the test with the command C>b -p foregnd.exe All screen images are compared successfully, even the scrolls. If you don't believe this, try instead the command: C>b -p -s foregnd1.exe The program foregnd1.exe is identical to foregnd.exe except that it adds one to the count that is output to the screen. Thus you will get a failure on each screenfull of 25 lines. This completes the tutorial. The remainder of the manual is a reference section listing all of BLOODHOUND's features. EGMay 8, 1988 Page 12FH EGBloodhoundFH EG 6.0 COMMAND LINE OPTIONS FH EG 6.1 "-r" RECORD TEST FH Use this to record keystrokes all keystrokes entered, for example: C>b -r foregnd.exe arg1 arg2 where "arg1", "arg2" etc. are command line arguments to "foregnd.exe". There is no limit to the number of keys that can be recorded since they are stored to disk (unless your disk is full, in which case you will get an error message to that effect). The recording of the test ends when you return your foreground program to DOS. After you have recorded all the keys you desire, you can then play them back with the "-m" option to create the accompanying screen images (see section 6.2). Note that it can be useful to use the "-r" option in conjunction with BLOODHOUND whenever you execute a program that is under development, regardless of whether you intend to create a test. This is because if you should ever have the situation occur whereby you get an unexpected bug, you have a complete record of all keys that were pressed. These keys then be played back via the "-p" option described in section 6.3. You can even set up an unobtrusive batch file so that executing your foreground program takes no more keystrokes than normal. An example would be a batch file called "foregnd1.bat" which would consist of the following single line: b -r foregnd.exe %1 %2 %3 %4 Thus you can execute your program by: foregnd1 arg1 arg2 arg3 arg4 Use of the "-r" option always creates a file with extension ".tst", with default stem "keys" so that the file created in the above example is "keys.tst". It is in this file that the keystrokes are recorded. However, another stem can be specified after the "-r", eg. "-rhello" creates file "hello.tst": C>b -rhello foregnd.exe arg1 arg2 The ".tst" file is an ASCII file which can be edited like any other file (see section 9.0). The only problem with the "-r" option is that if you execute a key sequence that that blows up your system (eg. produces the infamous message "parity error") the key file will be lost since it is closed only when the foreground program returns to DOS. To guard against this, use the "-c" option (close key file after each keystroke): EGMay 8, 1988 Page 13FH EGBloodhoundFH C>b -r -c foregnd.exe arg1 arg2 (the "-c" option is discussed in detail in section 6.5). EG 6.2 "-m" MAKE SCREEN IMAGES FOR TEST FH This option plays back the keystrokes recorded by the "-r" or "-a" options ("-a" option is described in section 6.4) and stops after each keystroke or screen scroll to capture the screen and stores it to disk to a file with extension ".cmp" (screen compare file). The correct format is: C>b -m foregnd.exe arg1 arg2 If no file name is specified after "-m" then it is assumed that the file "keys.tst" is to be played back and that the file contained resultant screen images is called "keys.cmp". Otherwise the "keys" is replaced by the indicated file stem, for example: C>b -mhello foregnd.exe arg1 arg2 In this example the "hello.tst" is played back to create file "hello.cmp". Note that the screen image is saved whenever a key is struck or whenever data scrolls off the screen. The scrolling logic is explained in more detail below. The screen normally scrolls when the foregound program executes commands such as "printf" statements in "C" or "PRINT" statements in "BASIC". It is the purpose of the BLOODHOUND scroll capture logic that all images thus created are recorded. Later when the same keystrokes that produced the scrolls are repeated, BLOODHOUND can then check that each scroll is identical (if it is desired not to have BLOODHOUND check the screen when it scrolls, then use the "-i" option to inhibit scroll, eg. "blood -m -i foregnd.exe" and "blood -p -i foregnd.exe"). Note that the scrolling capture works for any program that uses int 0x10 to do scrolling (with AH = 6 upon call to interrupt 0x10). The first time a 0x10 scroll occurs, the screen is saved (just prior to the actual scroll), thereafter it is saved only when the entire page scrolls off. For a full page scroll (such as that caused by "printf") this is 25 lines. The page length is calculated from the following formula: page length = DH - DL + 1 where DH, DL are the values in these registers (i.e. row #'s) when interrupt 0x10 is called. Note that the scrolling logic "resets" everytime a key is pressed. When the scroll "resets" it means that the screen will capture on the next scroll instead of waiting a number of scrolls equal to the page length. Thereafter the screen will capture after a number of scrolls equal to the page length. EGMay 8, 1988 Page 14FH EGBloodhoundFH Note that due to inherent DOS limitations and system timing, there is a small but finite chance that the scrolling logic may miss a screen, i.e. a screen may scroll past without being captured (if recording a test) or compared (if playing back a test). If this occurs you will see the error message "Missed scroll image" and then control is returned to DOS. You will then have to redo your record/playback test. The small possibility of missing a screen can be eliminated entirely by insuring that there is at least a 3 ms delay in between successive int 0x10 scroll calls for page length of 25 lines (delay must be proportionally longer for shorter page length) and a 70 ms delay between int 0x10 scroll calls if they occur in a high level language instruction such as "printf" (regardless of page length). However, these delays are generally not necessary. Note that should you desire to stop playback of the test while the "-m" option is invoked, press Ctrl-Alt and this will return control to DOS and return with an exit code of 1. EG 6.3 "-p" PLAYBACK TEST, "-s" STOP ON FAILURE FH After you have created your test via "-r" and "-m" options, you can play it back using "-p" option, for example: C>b -p foregnd.exe arg1 arg2 The result will be that "foregnd.exe" will be executed with keystrokes defined in "keys.tst" and each screen compared to the one recorded earlier using file "keys.cmp". If a failure occurs, then the beep will sound and both the "bad" screen and the "good one" will be stored to a file called "keys.err". When the playback is complete you may examine the good versus bad screens by using the program VIEW.EXE (see section 10.0). Note that during playback a special debug file is created with extension ".dbg" which is identical to the ".tst" file except that the test item "BP" (breakpoint) is inserted after each key that caused a failure. This file is used to allow programmers during debug to stop just prior to where the failure occurs and is discussed in detail in section 11.0. For now it suffices that the above playback example will create a debug file called "keys.dbg". If you specify a file name after "-p" then it becomes the stem for the test files, for example: C>b -phello foregnd.exe arg1 arg2 The above example plays back keystroke file "hello.tst" using screen image file "hello.cmp", deposits all compare errors in "hello.err" and creates a debug file called "hello.dbg". It is sometimes preferable to see the failures as they occur rather than store them for later viewing. This can be done with the "-s" (stop on failure) option: EGMay 8, 1988 Page 15FH EGBloodhoundFH C>b -p -s foregnd.exe arg1 arg2 The above invocation will cause BLOODHOUND to stop every time there is a failure and allow you to see the exact differences between the good screens and bad screens. Note that if you get more than 10 failures whether using the "-s" option or not, BLOODHOUND assumes that something catastrophic has happened and will abort the test and return to DOS. The maximum number of failures can be changed via a configuration file as explained in section 12.0. Also note that if even one failure occurs then when BLOODHOUND returns to DOS with an exit code = 1. This is useful if you are running a series of tests and want to abort the entire series if any fails. For example: blood -pmytest1 foregnd.exe if ERRORLEVEL 1 GOTO END blood -pmytest1 foregnd.exe if ERRORLEVEL 1 GOTO END blood -pmytest2 foregnd.exe if ERRORLEVEL 1 GOTO END :END Also note that playback can be interrupted by pressing "Ctrl Alt" which will return control to DOS with exit code of 1. When the test is complete, the results will be output to the screen: Test xxxx of foreground program yyyy now complete Number of screen failures = nnnn where: "xxxx" is name of test just executed "yyyy" is name of foreground program "nnnn" is number of screen compares that failed If the test had at least one failure, you will also see: To view test failures, type "VIEW xxxx" The program "VIEW.EXE" is discussed in detail in section 10.0. If you playback a test and there is no ".cmp" file you will see the message: Can't find file xxxx.cmp no screen comparisions will take place during playback of keystrokes where "xxxx" is the name of the test to be executed. This does not indicate a problem, i.e. the message is merely to remind you that no ".cmp" has been generated so that you are not lulled into a false security when no failures occur. EGMay 8, 1988 Page 16FH EGBloodhoundFH In the case of a test with no ".cmp" file, then when it concludes playback you will see the message: Playback xxxx of foreground program yyyy now complete which does not mention anything about number of failures. Note that if you experience the problem of where you record a test using the "-m" option, play it back immediately using the "-p" option and you get failures without changing the foreground program, this can occur for one of two reasons: (1) Your program outputs the time to the display and the time is different for each of the two runs. This problem might be solvable using the "TIME:" test item described in section 8.0 or it might be necessary to disable output of the time altogether as describe in section 16.0 (HINTS AND SUGGESTIONS) section (2). (2) Your program uses the timer interrupt to output data to the screen (other than the time as described above). This can cause a problem since the screen gets updated asynchronously to when the keyboard is read which is when the screen is captured. The solution is to assert a time delay between each key so that the screen has had enough time to "settle" before the next keystroke. A delay can be specified in 1/18's of a second (clock ticks) by the statement "delay xxx" in config file "b.cfg" where "xxx" is the number of 1/18's of a second desired. Another problem is that certain programs flush the keyboard periodically and this can cause keystrokes in the test program to be missed. By putting a timer tick delay between keystrokes, this problem can be eliminated. It is also possible to add a "power_on_delay" which delays execution at the a number of clock ticks at the start of the program. This is useful if you are experiencing spurious errors at the start of your program. You may have to experiment to determine exactly what delays are required. For example, if you were recording a spreadsheet made with Lotus 123 (registered trademark, Lotus Corp) then you would need a delay between keystrokes of at least 2 timer ticks. Use of config file "b.cfg" is discused in detail in section 12.0. EG 6.4 "-a" APPEND TO TEST FH The "-a" option is used when you have created a test that you wish to add to. Before appending to a test, however, you must first manually delete from the ".tst" file whatever keystrokes returned your foreground program to DOS. In the tutorial in section 5.0, we had a foreground program that looked like: N o w sp i s sp t h e sp t i m e sp f o r sp a l l sp g o o d sp m e n F10 EGMay 8, 1988 Page 17FH EGBloodhoundFH Recall that "F10" returned the foreground program to DOS. You must therefore edit the program so that it looks like: N o w sp i s sp t h e sp t i m e sp f o r sp a l l sp g o o d sp m e n Now execute the following batch command: C>b -a foregnd.exe This will play back the test "keys.tst" and when complete a message will appear that says: Appending to test "keys" Now you can add to your test just as if you had the "-r" option on. If you specify a file name after the "-a" then this becomes the file name of the test you are appending to, for example: C>b -ahello foregnd.exe The above command appends to the test "hello.tst". Note that the playback of the original test can be interrupted at any time by pressing "Ctrl - Alt" and you will return to DOS with an exit code of 1. EG 6.5 "-c" CLOSE TEST FH This option is used to save information that would be lost if during recording or playback of a test, the keyboard froze or the screen blew up, i.e. control was lost. The effect of the "-c" option is to close after each keystroke the data file that would otherwise be lost. The drawback with this approach is that it slows down operation considerably. The "-c" option can be used in conjunction withthe "-r", "-a", or "-p" options, for example: C>b -r -c foregnd.exe C>b -a -c foregnd.exe C>b -p -c foregnd.exe In the first two of the above examples, the ".tst" file that is being recorded is closed after each keystroke. In the last example, the ".dbg" file that is being created is closed after each keystroke. Thus any keystroke that causes a problem that blows up the system will be included in the ".tst" or ".dbg" files which get closed just before the keystroke does its damage. Note that it is possible to eliminate the delay caused by closing a file after every keystroke if you use a non-volatile RAM disk on which to store the files. In such a case you must also tell BLOODHOUND the drive EGMay 8, 1988 Page 18FH EGBloodhoundFH letter of the RAM disk. This is done with the "-d" option, for example: C>b -r -c -de foregnd.exe The letter of the drive follows the "-d" so that in the above example, the file keys.tst will be written to drive "e:". A manufacturer of non-volatile RAM disks is Santa Clara Systems Inc., 1610 Berryessa Road, San Jose, Ca. 95133, (408) 727-6700. EG 6.6 "-o" OUTPUT SCREEN COMPARISIONS TO PRINTER FH As well as writing the test results to the ".err" file, BLOODHOUND allows you to output the results to your printer. To do this, add the "-o" option before you specify the foreground program, eg. C>b -p -o foregnd.exe This will causes all good screens/bad screens to be output to the printer while the test executes. Note that no screen attributes or colors are output to the printer so that if your good screen versus bad screen differs only in color or attribute, the printer outputs will be identical. In such a case you must examine your test results by viewing the good screen/bad screens directly on the monitor using the program "VIEW.EXE" described in section 10.0. EGMay 8, 1988 Page 19FH EGBloodhoundFH EG 7.0 SCREEN CAPTURES UNDER PROGRAM CONTROL FH There may be some occasions when you wish want to decide to capture test screens under control of your program in addition to the automatic captures that occur with each keystroke and each scroll. This need could occur, for example, when your program is controlling external processes and the program advances not so much by user keystrokes but by what electronic inputs it receives. The solution is to have your program output to the screen the status of what you are controlling. Then your program calls a BLOODHOUND-defined software interrupt which captures that screen to disk. During playback, the same software interrupt will compare the "good screen" captured earlier to the "new" screen and report any difference. The way that the screen is captured is to invoke interrupt the "capture screen interrupt", 0xfd. For example, consider the following assembly language program: LOOP: MOV AH,8 INT 21H ;READ KEY INTO AL CMP AL,'X' ;WAIT FOR KEY 'X' JNE LOOP INT 0FDH ;WHEN IT ARRIVES CAPTURE SCREEN The above program captures the screen whenever "x" is inputted into the keyboard. The keyboard input could just have well have been an electronic input after which a lot of data could be dumped to the screen and INT 0xfd invoked to save the screen. Note that screen captures via interrupt 0xfd will occur only when the test is played back with the "-m" option. Thus the correct procedure is thus to first create a test with "-r" of all the keystrokes that your system needs. Then generate the test screens with the "-m" option which plays back all keys and will capture the screen for each key and will also capture the screen everytime interrupt 0xfd is called. During screen compare playback, i.e. "-p" option, whenever 0xff is asserted then the screen image at that time is compared to the one captured when 0xff was asserted during "-m" playback. Note that if the foreground program has changed so that it no longer asserts 0xfd where it did before, then the screen comparision will fail since the previously saved image from 0xfd will be compared to the screen belonging to the next keystroke. To restore the synchronization, simply re-generate the tests using the "-m" option. Another consideration is during normal operation, when your foreground program is executed without BLOODHOUND. At such a time when it asserts interrupt 0xfe it will go into never-never land since there will at that time be nothing defined at that interrupt. The way to solve this problem is to have a special command line argument for your foreground program EGMay 8, 1988 Page 20FH EGBloodhoundFH called, for example, "test_mode" that indicates BLOODHOUND is running and interrupt 0xfe can be safely asserted. This technique is described in more detail in section 11.0. EGMay 8, 1988 Page 21FH EGBloodhoundFH EG 8.0 SETTING OF TIME AND DATE FH If your foreground program displays the time and date on the screen then you will have a problem whereby you will always get errors when you playback your test since the time and date will be different each time. The solution is to have BLOODHOUND set the system time and date to a known value while you are recording the test. Thus when you playback your test it will always start with the same time and date. This can be done by manually editing the ".tst" file so that you insert "TIME:hh:mm:ss" and "DATE:yy/mm/dd" into your test, for example: TIME:13:06:00 DATE:80/1/23 h e r e sp a r e sp t h e sp k e y s After the time and date have been edited into the ".tst" file, then execute BLOODHOUND with the "-m" option to generate all the screens with the time and date starting from where you indicated in using "TIME:" and "DATE:". Note that the above example, BLOODHOUND sets the time to 1:06 pm, January 1, 1980 and then executes the keys ("TIME:" and "DATE:" can be used anywhere in the test). Time must be in the form in the form HH:MM:SS where HH varies from 0 to 23, and MM and SS varies from 0-59. "SS" is optional but you still must have all 3 semicolons, eg. "14:06:". Date must be in the form MM/DD/YY where "MM" varies from 1-12, "DD" varies from 1-31 and "YY" varies from 80 - 99. There exists a potential problem with the time setting and that is if when you playback your test, you capture the screen at a time that is one second different than when you recorded it. Should this type of problem occur, the only solution is to inhibit the display of time as explained in section 16.0, HINTS AND SUGGESTIONS, item (2). When BLOODHOUND exits to DOS the system time will be automatically set to the "real" time within 1/18 second of what it would have been had the "TIME:" feature not be invoked. The date will also be restored to what it would have been had not the "TIME:" or "DATE:" feature been invoked. Manual editing of tests to include such features as "TIME:" and "DATE:" is discussed in detail in the next section. EGMay 8, 1988 Page 22FH EGBloodhoundFH EG 9.0 MANUAL EDITING OF TESTS FH Each test recorded becomes an ASCII file with extension ".tst". This file can be edited with any ASCII editor. The test file "keys.tst" in the tutorial of section 5.0 has the following contents: N o w sp i s sp t h e sp t i m e sp f o r sp a l l sp g o o d sp m e n F10 The test is nothing but an ASCII file listing the keys pressed separated by spaces. Note, however, that some keys have special notations: notation key sp space bar tab tab key enter enter/return home home end end PgUp page up PgDn page down Ins insert Del delete rt cursor right lf cursor left up cursor up dn cursor down esc escape bs backspace Function keys are designated "F1, F2, F3, F4, F5, F6, F7, F8, F9, F10". The "alt", "shift" and "ctrl" functions are designed by the prefixes "a-", "s-" and "c-" respectively, eg. a-F1 alt F1 s-tab shift tab c-home control home All key notations are case insensitive, i.e. "home" is equivalent to "HOME". Keys with codes 1-6 and 14-27 (eg. ctrl-s which gives code ASCII 19) are stored literally (eg. double exclamation point for 19). Time and date settings have the prefixes "TIME:" and "DATE:" respectively followed by the desired time and date. Breakpoints are indicated by "BP" and discussed in section 11.0. A table of these non-key test items is shown below: EGMay 8, 1988 Page 23FH EGBloodhoundFH test item format example breakpoint BP BP set date DATE:MM/DD/YR DATE:1/2/87 set time TIME:HH:MN:SS TIME:15:30:00 You may edit the test file with any ASCII editor if you wish to modify the test. Note, however, that any test edit will require re-generating the screens using the "-m" option. EGMay 8, 1988 Page 24FH EGBloodhoundFH EG 10.0 UTILITY VIEW.EXE FH There exists a utility program "view.exe" which allows you to examine the disk files that contain all the screen comparision errors. Recall that if any errors have occurred they will be output to a file of form "testname.err" which may be examined by VIEW. For example, suppose you had created a test called "badtest" that you executed via the batch playback: C>b -pbadtest foregnd.exe Then when the test finished executing you found you have 4 compare errors in "badtest.err". To see these errors execute: C>view badtest The screen then displays: EG ┌──────────────────────────────────────────────────────────────────────────┐ │ View Screen Failures V1.00 Sunday March 8, 1987 2:06 am │ └──────────────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────────────────┐ │ Screen Failure 1 of 4 for test "badtest" │ ├──────────────────────────────────────────────────────────────────────────┤ │Press "F" repeatedly to flip between bad screen/good screen ('esc' to │ │return to this menu) │ │ │ │Press "D" repeately to flip between difference in bad screen/good screen │ │("esc" to return to this menu) │ │ │ │Press F10 to select next screen failure, press F9 to select previous │ │ │ │Press "home" to return to first screen failure │ │ │ │Press "esc" to return to DOS │ └──────────────────────────────────────────────────────────────────────────┘ Figure 4: VIEW menu for screen compare failure FH You can flip to the good screen/bad screen just as you did during playback of manual mode or press F10 to advance to the next failure and F9 to return to the previous one. EGMay 8, 1988 Page 25FH EGBloodhoundFH Note that if no test is specified when VIEW.EXE is invoked, then the test error file defaults to "keys.err". EGMay 8, 1988 Page 26FH EGBloodhoundFH EG 11.0 PROGRAM BREAKPOINTS FH A breakpoint in your test program is used to allow you to interrupt the playback of a test under control of a debug program (eg. DOS "debug.com"). This allows you to examine the internal status of the currently executing foreground program. Breakpoints are put into a test program by use of the string "BP" after the keystroke you wish to break on. You can thus manually edit your ".tst" file and insert "BP" whereever you wish. In order to use the breakpoint, you must re-write your foreground program to invoke interrupt 0xff after each key is input. During playback, if the "BP" is encountered, interrupt 0xff will return AX = 1 rather than AX = 0. This can be sensed by the foreground program so that it can trap to a breakpoint location. For example, suppose we had a program "mytest.tst" that looked like: N o w sp i s sp t h e sp t i m e Now suppose we edited it to look like: N o w sp i s sp t h e BP sp t i m e Assume our routine to read the keyboard interrupt originally looked like: read_keyboard() { int scan,key; scan =kbin( key); } Now assume that it was modified to be: read_keyboard() { int scan,key; scan =kbin( key); int86(0xff, inregs, outregs); /* test for breakpoint */ if (outregs.x.ax == 1) breakpoint(); } In above modified keyboard routine, as soon as the character "e" (in "t h e") is input the function "breakpoint()" will be executed. This is because the call to interrupt 0xff checks to see if the item after the keystroke just received is a "BP" and if so will return AX = 1. EGMay 8, 1988 Page 27FH EGBloodhoundFH The playback command for test with breakpoints is the same as for those without i.e. C>b -pmytest foregnd.exe Note that whenever BLOODHOUND encounters a breakpoint it stops dead in the water, i.e. no more keys are played back, until the breakpoint is cleared. This is done with interrupt 0xfe: read_keyboard() { int scan,key; int86(0xff, inregs, outregs); /* clear any breakpoint that may be active */ scan =kbin( key); int86(0xff, inregs, outregs); /* test for breakpoint */ if (outregs.x.ax == 1) breakpoint(); } There is one obvious problem with the above approach. If the foreground program is running without BLOODHOUND then it will crash since it will execute interrupt 0xff without that interrupt being defined. The way around this problem is to create a flag called, for example, "test_mode" which if set allows the interrupt to be called. This flag would get set only if the appropriate command line argument were supplied to the foreground program which is done only when it is executed by BLOODHOUND. Using the above reasoning, we would once again modify our program to be: void main(argc,argv) int argc; char *argv[]; { int test_mode = 0; /* if this flag is set, then we have detected "test_mode" on the command line */ if (!stricmp(argv[1],"test_mode")) { test_mode = 1; } /* main program here */ } read_keyboard() { EGMay 8, 1988 Page 28FH EGBloodhoundFH int scan,key; if (test_mode) { int86(0xfe, inregs, outregs); /* clear any breakpoint that may be active */ } scan =kbin( key); if (test_mode) { int86(0xff, inregs, outregs); /* test for breakpoint */ if (outregs.x.ax == 1) breakpoint(); } } The program modified above to include interrupt 0xfe will thus continue to read keys from the test after the function "breakpoint()" returns. BLOODHOUND breakpoints are most useful in conjunction with a program debugger. Suppose that we wanted to execute the above foreground program under the DOS "debug.com". Then we would playback the test using the following command: C>b -p -b debug.com foregnd.exe test_mode The above command does the following: (1) BLOODHOUND is executed in playback mode with test "keys.tst" (2) The foreground program is "debug.com" (3) The argument to "debug.com" is "foregnd.exe test_mode" (4) Debug executes after having loaded "foregnd.exe" and you will see the "-" prompt. (5) The "-b" option forces an immediate breakpoint. This is to prevent test keystrokes from being played back into the debugger. (6) You can now type "g" to start execution of "foregnd.exe" under debug.com Note that the use of debugger will affect the screen comparisions adversely since after debug loads you will see the "-". Then you must type "g" to start executing which becomes in effect a key inputted to the foregnd.exe program. Thus the screen comparisions will fail. The solution to the above problem is to copy the ".tst" file to a ".dbg" file and execute that. For example: C>copy keys.tst keys.dbg C>b -pkeys.dbg debug.com foregnd.exe test_mode EGMay 8, 1988 Page 29FH EGBloodhoundFH That is, any test file with extension ".dbg" automatically does not do screen comparisions even if a ".cmp" file exists. Note that whenever a test is played back via option "-p", a ".dbg" file is automatically created with "BP" inserted after each key that caused a failure (unless the test being played back has extension ".dbg"). Suppose, for example, we had a test called "mytest.tst" that looked like: t h i s sp i s sp a sp t e s t Now suppose that during playback the screen failed after the second "s". Then the automatically generated file "mytest.dbg" would contain: t h i s sp i s BP sp a sp t e s t You can then playback the debug file in the same manner as described above. Your breakpoint will occur just AFTER the "s" is input to the keyboard but BEFORE the program logic takes off that demolishes the screen. Note that if you get a failure from either a scroll or a "screen capture under program control", you will see the BP just after the key that started the scroll or the last key executed before the "screen capture under program control". For example: F1 F9 h e l l o F5 BP t h i s If key F5 started a scroll and there were one or more failures, then you would see the "BP" just after F5 as shown. This could also be a test where the foreground program captured a screen using interrupt 0xfd sometime after F5 was executed. To see a real example of how to execute a debugger in conjunction with BLOODHOUND and a foreground program, execute the following from DOS (assuming you have DOS "debug.com" accessible): C>b -ptest.dbg -b debug.com foregnd.exe test_mode After debug has loaded an executed, you will see the "-" prompt. Note that we introduce here the "-b" option which means "set breakpoint". This forces a breakpoint upon power-up and is necessary to keep the test keys from feeding into the debugger rather than the program it is testing. Note that this initial forced breakpoint gets cleared right away in the foreground program where it asserts interrupt 0xfe. The file "test.dbg" that you are about to playback looks like: N o w sp i s sp t h e BP sp t i m e We assume that there is a program bug just after where the first "e" is executed. We want to stop in trap function "breakpoint" at that point. It so happens that this function resides at 9F:13A. Therefore look at your value of CS:IP and at this number to it. If CS:IP were, for example, 4085:0100 then after the above addition you get 4124:23A. Now EGMay 8, 1988 Page 30FH EGBloodhoundFH execute the debug command: g4124:23A and your program will playback as normal, finally stopping at the start of function "breakpoint()". To continue merely type "g" and you the breakpoint will clear since interrupt 0xfe gets called the next time thru the keyboard function. EGMay 8, 1988 Page 31FH EGBloodhoundFH EG 12.0 CUSTOMIZING BLOODHOUND FH The following parameters can be customized via a customer configurable file "b.cfg". 1. Max number of program failures before playback automatically terminates. 2. Interrupt numbers for "check_breakpoint", "clear_breakpoint", "capture screen". 3. Number of 1/18's of a second to delay between keystrokes. Useful for those programs which use the timer interrupt to output to the screen and it is necessary to wait a while after each keystroke for the screen to "settle" before capturing it. This also is useful for those programs which "flush" the keyboard at various points to make sure there are no keys active. Normally, the default of 1 clock tick delay will foil most flushing so that no keys are lost. However, longer delays can be created if necessary. 4. Number of 1/18's a second to delay at start of program. Useful if you must delay at the start of the program to allow your program and screen to "settle" before starting the test. The parameter names, default values and allowable ranges are as follows: Parameter name Default Allowable range max_failures 10 1-1000 check_breakpoint 0xff 45 - 0xff clear_breakpoint 0xfe 45 - 0xff capture_screen 0xfd 45 - 0xff delay 1 0 - 32767 power_on_delay 18 0 - 32767 Note that upon delivery, there is no b.cfg, i.e. the defaults hold. A sample b.cfg file might be: max_failures 20 delay 10 set_breakpoint 0x50 (other values are defaults) EGMay 8, 1988 Page 32FH EGBloodhoundFH EG 13.0 BLOODHOUND FILE STRUCTURE FH The following files are necessary to execute the BLOODHOUND PROGRAM: BLOOD.EXE VIEW.EXE SYS$MSG.DAT SYS$ERR.DAT $RUN.OVL IBM$RUN.OVL b.cfg (optional) The following file extensions are BLOODHOUND data files: Extension File type .tst test program of keystrokes .cmp contains screen compare images .dbg test program with breakpoints after errors .err error file (good screens vs. bad screens) EGMay 8, 1988 Page 33FH EGBloodhoundFH EG 14.0 MEMORY REQUIREMENTS FH Executing BLOODHOUND will reduce available RAM memory by about 127K. However, BLOODHOUND is not memory resident so that when you return to DOS all this memory is again available. There is no limit on the size of disk files other than the size of the hard disk. The disk files are those with extensions ".tst", ".cmp", ".err", ".dbg". Typically storage requirements for these files are: FILE TYPE REQUIREMENTS .tst approx 3 bytes/keystroke .dbg approx 3 bytes/keystroke .cmp approx 300 bytes/screen .err 8000 bytes per screen compare failure EGMay 8, 1988 Page 34FH EGBloodhoundFH EG 15.0 COMPATIBILITY WITH SUPERKEY FH BLOODHOUND is compatible with SUPERKEY (registered trademark, Borland international), with one limitation. If you should use SUPERKEY to define key F1 to be "this is a test", for example, then whenever F1 is pressed during record mode, you will record "this is a test" into your test program and not "F1". If you should manually edit your test so that you inserted "F1", then when this key is played back it will playback "this is a test". Note, however, that the screen will be captured only once for this entire key sequence. Another consideration is that the test program must not have as its last key a SUPERKEY defined keystroke. For example, the test program: F1 F10 will work fine if F1 has been defined by SUPERKEY but not if F10 has been defined. EGMay 8, 1988 Page 35FH EGBloodhoundFH EG 16.0 HINTS AND SUGGESTIONS FH (1) Break up the test of your program into small modules which then can be executed as a series of batch commands. For example, suppose you create test modules "mytest1", "mytest2", "mytest3". You could then create a batch file called "test.bat" whose contents were: blood -pmytest1 myprog blood -pmytest2 myprog blood -pmytest3 myprog Each of the above test modules could test a distinct feature of your program. This makes maintaince of your test files much easier since a change in one feature of your program (eg. a different keyboard definition) will not impact the other recorded tests. (2) It is conceiveable that your foreground may have part of a display that is continually varying that would cause you to get many screen compare errors even though nothing is wrong with your program. An example would be a line on your main menu that displayed something like: xxxxx bytes remaining "xxxxx" will vary with the size of your program (and the size of future releases of BLOODHOUND). The only solution is to have a flag (such as the one called "test_mode" described in section 11.0) within your program that senses your are in BLOODHOUND and that causes such screen output not to occur. Another example of a continually varying foreground is the display of real time. Even though the time can be set via the "TIME:" test item, the seconds is not guaranteed to tick over at the same keystroke each run of the test, introducing compare errors. The only solution in such a case is to disable the display of time altogether. (3) Do not start any background printing tasks via command "print.com" before executing BLOODHOUND as this will caus the system to hangup. EGMay 8, 1988 Page 36FH EGBloodhoundFH EG 17.0 LIMITATIONS FH The following are limitations to Bloodhound: (1) Note that when reading keys from stdin (eg. "scanf()" function in the "C" language), the screen will be captured only at the start of the read. For example, if you type "this is a test (enter) hello (enter)" in response to two scanf instruction then the screen is captured just prior to the "t" in "this" and "h" in hello. In such a case the test looks like: t h i s sp i s sp a sp t e s t enter h e l l o enter If both screens fail then the automatic breakpoints in the ".dbg" file will be inserted after the enter's, i.e.: t h i s sp i s sp a sp t e s t enter BP h e l l o enter BP Thus if you had a keyboard routine with scanf's and wanted to test for breakpoints you would write it thusly: read_keyboard() { char s[81]; if (test_mode) { int86(0xfe, inregs, outregs); /* clear any breakpoint that may be active */ } scanf("%s",s); if (test_mode) { int86(0xff, inregs, outregs); /* test for breakpoint */ if (outregs.x.ax == 1) breakpoint(); } } Note that when dealing with stdin such as scanf's and you want to insert a breakpoint manually, do NOT insert the breakpoint before the "enter", i.e.: t h i s sp i s BP sp a sp t e s t enter h e l l o enter WRONG t h i s sp i s sp a sp t e s t enter BP h e l l o enter RIGHT This is because "BP" always causes BLOODHOUND to stop inputting keys and the result will be that the system will hang since the the scanf is never completed and the breakpoint is never cleared. EGMay 8, 1988 Page 37FH EGBloodhoundFH (2) Also note that when doing input from stdin that software interrupt 0xfc is reserved for internal use (3) The current version of Bloodhound will not properly record and playback keystrokes that use the control key in conjunction with two other alpha keys, eg "KD" such as found in WordStar. EGMay 8, 1988 Page 38FH EGBloodhoundFH EG 18.0 ERROR MESSAGES FH Below follows an alphabetic listing of error messages and their significance ("nnnn" is argument to error message). Can't find file nnnn, no screen comparisions will take place during playback of keystrokes" Explanation: This is not really an error. It merely says that the test you specified has no ".cmp" and that no comparisions will take place. This occurs if you record a file with the "-r" option and immediately play it back with the "-p" and do not make screens with the "-m". The message is to keep you from thinking that your test has passed. Can't have "nnnn" and "nnnn" options simultaneously Explanation: The two options specified were mutually exclusive. You can't for example, record keystrokes ("-r") and generate screens ("-m") at the same time. Can't load foreground program "nnnn". Does it exist? Is there enough memory Explanation: Either the foreground program you specified did not exist or there was not enough memory to load it. "Can't open file "nnnn" Explanation: The indicated file cannot be opened. This is an internal error and should not occur. Error closing file "nnnn". Explanation: This error might be due to disk full. If disk is not full then it is an internal error. Error opening file "nnnn". Does it exist? Explanation: This will occur if you specify an illegal disk drive while using the "-d" option. At any other time this error should never occur and is internal error. Error putting char to file Explanation: this error should never occur is internal error. Error reading ".cmp" file. Do you have the correct file? Or have you edited the key file without re-generating the screen images? Perhaps you EGMay 8, 1988 Page 39FH EGBloodhoundFH need to re-execute BLOODHOUND with the "-m" option. Explanation: This occur occurs whenever something has gone wrong with the ".cmp" file. Somehow you have a ".cmp" file that does not match the currently executing ".tst" file. You may have edited your ".tst" file or changed your foreground program without re-generating the ".cmp" file using the "-m" option. Error reading file "nnnn". Explanation: This error should never occur and is internal error. Error seeking file "nnnn". Explanation: This error should never occur and is internal error. Error writing file "nnnn". Could be disk full. Explanation: It was not possible to write the indicated file to disk. The most likely reason is disk full. If your disk is not full then this should be regarded as an internal error. Illegal date "nnnn". The correct format is mm/dd/yr where "yr" must be between 80 and 99 inclusive. Explanation: The date you specified must match the above format. Illegal offset in ".cmp" file. Do you have the correct ".cmp" file? Explanation: same as for "Error reading ".cmp" file above Illegal time "nnnn". The correct time format is "hr:mins:secs" where hrs can vary from 0-23, and mins/secs can vary from 0-59. "secs" is optional, however, ":" must be specified, eg. "14:06:". Explanation: The time you specified must match the above format. "nnnn" is illegal disk drive letter Explanation: you attempted to specify a disk drive that is not valid, eg. "-dE" when drive "E" was not on your system "nnnn" is illegal option Explanation: the option after the "-" was not recognizable Missed scroll image. Due to inherent DOS timing considerations, EGMay 8, 1988 Page 40FH EGBloodhoundFH BLOODHOUND failed to capture/compare a scroll image. The record/playback of your test cannot continue. Explanation: DOS has some internal limits that may cause BLOODHOUND to miss a scroll capture if the screen scrolls too fast. Consider inserting a 70 ms time delay after each high level "print" type statement (eg. "printf"). No foreground program specified Explanation: You failed to specify after the "-m", "-r" or "-p" option a program to be executed. parameter "nnnn" in b.cfg has unrecognized value "nnnn" Explanation: You gave an illegal value to a parameter in "b.cfg" option eg "max_failures" greater than 1000. parameter "nnnn" illegal Explanation: You specified a parameter in b.cfg that was illegal, eg. "max_failure" rather than "max_failures" Test "nnnn" not found Explanation: You specified a test name that does not exist. The test item "nnnn" is not valid. Explanation: You may have mispelled a key such as "esk" instead of "esc" or you mispelled a test function, eg. "DAT:1/5/85" instead of "DATE:1/5/85. Your test had more than "nnnn" failures. Explanation: The playback of your test exceeded the maximum number of allowed failures. The default number is 10. You may specify this to be any number you wish as explained in section 12.0. EG 18.0 DISCLAIMER FH This product is supplied on an "as is" basis only with no warranty of any kind. If it malfunctions, then Richard Fencel is not liable for any damages. EGMay 8, 1988 Page 41FH ----------------end-of-author's-documentation--------------- Software Library Information: This disk copy provided as a service of The Public (Software) Library We are not the authors of this program, nor are we associated with the author in any way other than as a distributor of the program in accordance with the author's terms of distribution. Please direct shareware payments and specific questions about this program to the author of the program, whose name appears elsewhere in this documentation. If you have trouble getting in touch with the author, we will do whatever we can to help you with your questions. All programs have been tested and do run. To report problems, please use the form that is in the file PROBLEM.DOC on many of our disks or in other written for- mat with screen printouts, if possible. The P(s)L cannot de- bug programs over the telephone. Disks in the P(s)L are updated monthly, so if you did not get this disk directly from the P(s)L, you should be aware that the files in this set may no longer be the current versions. For a copy of the latest monthly software library newsletter and a list of the 1,000+ disks in the library, call or write The Public (Software) Library P.O.Box 35705 - F Houston, TX 77235-5705 (713) 665-7017